Why should you care about the examples?
Automated tests give us amazing leverage. If something is not quite right, hard to understand or inefficient, then you might need to change it. What would happen if you could change the implementation of something and know with near certainty that you did not break anything? What if your requirements change and force a redesign? Maybe you are just adding to an existing class. Did what you just do break it? How can you know? The answer is automated tests (or examples in this case). What if you need to build something from the ground up? If you happen to be rewriting something with existing examples, then you have an executable specification from which to work.
I have had several such experiences. I wrote the obligatory login service for a single application. I wrote several unit tests (not even following TDD, but rather I was test infected) to make sure I got all of the business rules right (there were maybe 70, give or take). After we deployed the first application, we used the first application as a prototype for a suite of applications. A suite of applications, of course, requires single sign-on. This required significant rewriting both because of new requirements as well as a need to extend the base architecture to support multiple applications. I had 70 working unit tests. I added around 40 more tests to accommodate the new requirements. Also, with the new system, the underlying implementation became a mess and strongly suggested refactoring to the state design pattern. While all of this was going on, I keep the unit tests passing. It make a daunting task much easier.
So unit tests are a valuable asset and should be treated with the same (maybe even more) TLC that you'd treat production code. Thus, keep your tests clean and well written as you work.
Automated tests give us amazing leverage. If something is not quite right, hard to understand or inefficient, then you might need to change it. What would happen if you could change the implementation of something and know with near certainty that you did not break anything? What if your requirements change and force a redesign? Maybe you are just adding to an existing class. Did what you just do break it? How can you know? The answer is automated tests (or examples in this case). What if you need to build something from the ground up? If you happen to be rewriting something with existing examples, then you have an executable specification from which to work.
I have had several such experiences. I wrote the obligatory login service for a single application. I wrote several unit tests (not even following TDD, but rather I was test infected) to make sure I got all of the business rules right (there were maybe 70, give or take). After we deployed the first application, we used the first application as a prototype for a suite of applications. A suite of applications, of course, requires single sign-on. This required significant rewriting both because of new requirements as well as a need to extend the base architecture to support multiple applications. I had 70 working unit tests. I added around 40 more tests to accommodate the new requirements. Also, with the new system, the underlying implementation became a mess and strongly suggested refactoring to the state design pattern. While all of this was going on, I keep the unit tests passing. It make a daunting task much easier.
So unit tests are a valuable asset and should be treated with the same (maybe even more) TLC that you'd treat production code. Thus, keep your tests clean and well written as you work.